Experiences with Object Group Systems: GARF, Bast and OGS

For a couple of decades now, many projects have been devoted to the design and implementation of object based concurrent and distributed systems, mainly focusing on building support for object based concurrency control, remote object invocation and object migration [5]. Very few however have been devoted to building support for replication and object groups. This is actually not surprising as most object based distributed systems have been experimented on academic applications for which fault-tolerance is rarely a mandatory feature. This situation has recently changed when distributed objects became the cornerstone of industrial standards such as CORBA and DCOM. Applications in various areas are being developed or ported on object based distributed systems, including those with strong requirements for continuous availability such as air traffic control, telecommunication, medical and financial systems. By encapsulating a set of entities that cooperate to achieve some common goal, the group abstraction has proven to be very convenient for distributed programming, particularly for achieving continuous availability (fault-tolerance) through replication. Although the group abstraction is intuitive, the underlying techniques required to implement group communication and group membership pose difficult problems. Furthermore, providing the group abstraction at the application level is far from being trivial. In short, process group toolkits (e.g., Isis) provides the abstraction of group at the process level, whereas programmers typically compose applications at the ”object” level. Most of the papers dedicated to object groups mainly describe specific techniques to integrate object group supports in particular systems, e.g., Psync [37], Amoeba [46], Emerald [7], Arjuna [34], and CORBA [35, 11, 1]. The motivations and limitations of various design and implementation choices are however rarely discussed.